lwcsecinfra

Building This Website with Azure Static Web Apps, AZ-104 Knowledge, and DevOps

📅 Created: 2026-04-10 | ⏱️ Read Time: 7 mins

Building This Website with Azure Static Web Apps, AZ-104 Knowledge, and DevOps

Overview

This project documents how I built, deployed, and improved my personal portfolio website by using Azure Static Web Apps, GitHub, Cloudflare, and a structured Git-based workflow.

The goal was not only to publish a website, but also to treat the work as a practical cloud and DevOps project. Instead of viewing the site as only a front-end exercise, I used it to demonstrate deployment workflow, troubleshooting, validation, and production-minded decision-making.

Why I Built This Project

I wanted this website to serve two purposes at the same time:

  1. Present my technical profile in a clean and professional format
  2. Demonstrate practical Azure, Git, and DevOps skills through a real deployment project

This project became a hands-on lab for applying cloud thinking to a real website, including structured updates, staged validation, and post-deployment checks.

Why I Chose Eleventy

11ty

I chose Eleventy (11ty) because it is lightweight, flexible, and well suited for a content-focused technical website.

For this project, Eleventy was a practical choice because:

  • it works very well with Markdown-based content
  • it has a simple structure that is easy to understand and maintain
  • it supports Nunjucks layouts, which made it easier to build reusable page templates
  • it does not require a heavy front-end framework for a static portfolio site
  • it fits well with Azure Static Web Apps, where static output is ideal for simple, fast deployment

I also wanted a workflow that stayed focused on content, structure, and deployment rather than unnecessary front-end complexity. Eleventy gave me that balance.

Technologies Used

  • Eleventy (11ty)
  • Markdown
  • Nunjucks
  • Git
  • GitHub
  • GitHub Pull Requests
  • Azure Static Web Apps
  • Azure Functions
  • Cloudflare DNS and security features

AZ-104 Knowledge Applied

This is not a direct AZ-104 lab, but the project reflects AZ-104-style thinking in practice.

Concepts applied include:

  • working with Azure-hosted services instead of local-only hosting
  • understanding cloud-based deployment flow
  • thinking in terms of production readiness
  • validating configuration changes before release
  • troubleshooting deployment and integration issues
  • managing a cloud-hosted resource with a structured workflow

This project helped reinforce an Azure administrator mindset: deploy, verify, troubleshoot, improve.

DevOps Practices Applied

I used this project to apply practical DevOps-style habits, even at a small scale.

These included:

  • version control with Git
  • feature branch workflow
  • pull request-based change review
  • preview validation before production merge
  • production deployment through Azure Static Web Apps
  • incremental improvement instead of direct live editing

This made the project more than a personal site. It became a small but realistic deployment workflow.

What I Built

The website includes:

  • a homepage introducing my technical direction
  • an About Me page
  • a Projects / Lab section
  • a first detailed project write-up
  • a managed Azure Functions API endpoint at /api/health
  • custom domain integration
  • HTTPS and Cloudflare-based edge configuration

This created a portfolio site that is both presentable and technically useful as a cloud project example.

Branch Workflow Used

I used a feature branch workflow to isolate changes from production.

Branches

  • Production branch: main
  • Feature branch: feature/pr-preview-test
  • Feature branch: feature/add-health-api

Process

  1. Created a feature branch for content and structure updates
  2. Pushed changes to GitHub
  3. Opened a Pull Request to main
  4. Used Azure Static Web Apps preview deployment to validate the changes
  5. Merged after verification
  6. Created another feature branch for Azure Functions API work
  7. Repeated the same workflow before production release

This kept changes isolated and made the deployment flow safer and easier to explain.

Why I Used Pull Request Preview

I used Azure Static Web Apps Pull Request preview environments so I could validate changes before releasing them to production.

That allowed me to:

  • review site updates in a staged environment
  • confirm that pages rendered correctly
  • check internal links and assets
  • reduce the risk of pushing broken changes directly to the live site
  • demonstrate CI/CD-style thinking in a portfolio project

This was one of the most valuable improvements in the project because it made the deployment process look and feel more like a real production workflow.

What I Validated Before Merge

Before merging changes, I used the preview deployment to check:

  • homepage rendering
  • Projects / Lab page rendering
  • project detail page rendering
  • internal links
  • layout and styling
  • static assets
  • general deployment behavior

I also used the staged workflow to verify that updates behaved correctly before they reached the production site.

Azure Functions Integration

To move beyond a purely static site, I added a small Azure Functions API endpoint:

  • /api/health

This endpoint returns simple status information and helped turn the project into a static + serverless portfolio example.

That was useful because it demonstrated:

  • Azure Functions integration with Azure Static Web Apps
  • a lightweight backend capability
  • structured API thinking
  • a practical example of expanding a static website into a cloud application

Custom Domain, HTTPS, and Cloudflare

I also connected the site to a custom domain and added Cloudflare as the DNS and edge layer.

This included:

  • custom domain setup
  • HTTPS validation
  • Cloudflare DNS configuration
  • www routing
  • root-to-www redirect
  • SSL/TLS mode configuration
  • production-style domain handling

These changes improved both presentation and operational quality. A custom domain makes the project feel more complete, and the Cloudflare integration added a stronger production mindset.

What Has Been Completed So Far

Completed work includes:

  • initial website structure
  • Azure Static Web Apps deployment
  • GitHub integration
  • Projects / Lab section
  • first project entry
  • Pull Request preview workflow
  • Azure Functions /api/health endpoint
  • custom domain and HTTPS
  • Cloudflare integration for DNS and edge handling

Current Value of This Project

This project demonstrates:

  • Git branching and Pull Request workflow
  • Azure Static Web Apps deployment
  • preview validation before production merge
  • Azure Functions integration
  • custom domain and HTTPS setup
  • Cloudflare DNS and edge configuration
  • practical troubleshooting and step-by-step improvement

It is a small project, but it reflects real cloud deployment thinking rather than only local development.

What I Plan to Improve Later

This website will continue to evolve. Planned future improvements include:

  • clearer project navigation
  • more cloud and security lab write-ups
  • additional API endpoints
  • stronger content organization
  • further polish to presentation and structure
  • continued improvement of the deployment workflow

Notes

This project was intentionally built and improved in stages.

The goal was to show real implementation, realistic troubleshooting, and iterative progress rather than pretending the final result appeared all at once.